To extend this concept to WebFlux, would it be more consistent to use the existing key "spring.http.converters.preferred-json-mapper" as the common entry point rather than introducing a new one "spring.http.codecs.preferred-json-mapper"?

To extend this concept to WebFlux, would it be more consistent to use the existing key "spring.http.converters.preferred-json-mapper" as the common entry point rather than introducing a new one "spring.http.codecs.preferred-json-mapper"?

Thanks for suggestion.

As I understood spring-http-codecs module is webflux alternative to webmvc's spring-http-conveters and it would not be very good to mix these concepts, even at the configuration level. Also spring already have some properties under spring.http.codecs so it can be confusing to users.

I also think that merging http-codecs with http-converters might be a good idea, but it is out of scope of this MR.

You're correct, @vpelikh, that property should not be used to influence both HTTP codecs and HTTP message converters. Please leave things as they are and we'll review your proposal more fully in due course.

Thanks for your contribution @vpelikh

We discussed this today and we don't think we should introduce such a property, because this property would expose three choices that aren't really applicable to WebFlux applications right now. Let me expand on that.

First, the Gson codec has been only recently introduced in Spring Framework after several community requests, but with an obvious limitation: the decoder cannot decode JSON to Flux<*> types because the Gson library itself doesn't offer a way to decode in a non-blocking way for reactive environments. As a first step, we would like to see if this codec finds its place in the community or whether its limitations are too important and should be reconsidered entirely.

Also, the Kotlin serialization support is somewhat different. This was initially considered as a possible configuration value for this property in MVC, but as seen in #47178 this codec should not be considered for "full JSON" support as it often needs another one for fallback in Kotlin environments.

That leaves us with a single option: Jackson. At this point, there is no need to surface this to developers with configuration properties given the current situation. We might revisit this in the future.

Thanks!

@bclozel, thanks for the deep explanation!
So, for now, if I want to have actuator and use kotlin serialization, do I have to add CodecCustomizer with the appropriate mapper?
And I saw you added mapper abstraction for actuator, but without kotlin serialization. Do you have plans to work on it in the near future? If not, I would like to make MR with it.

And I saw you added mapper abstraction for actuator, but without kotlin serialization. Do you have plans to work on it in the near future?

Actuator requires Jackson. We do not have any plans to support Kotlin Serialization there.